



Appt^/tdi x P 






UNIVERSITY OF COLORADO 


















(NASA-CR-163423) SOFTWARE DEVELOPMENT 
ENVIRONMENT, APPENDIX f (Colorado Univ. at 
boulder.) 12 p HC A02/MF A0 1 CSCL 09b 


N 30067 


Unol 

G 3/b 1 29J3S 


DEPARTMENT OF COMPUTER SCIENCE 




Technical Report 





Technical Report 





SOFTWARE DEVELOPMENT ENVIRONMENTS 

William E. Riddle 
Department of Computer Science 
University of Colorado at Boulder 
Boulder, Colorado 80309 


CU-CS- 182-80 October, 1980 


This work was supported. In part, by grant NSG 1638 
from NASA Langley Research Center. 



RSSM/101 
Prepared for a panel 
at Compsac 80 Chicago. 
(October 1980). 
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William E. Riddle 
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Abstract : The purpose of this panel Is to provide some 
assessment, based on experience, of the current status In 
the area of software development environments. This paper 
provides a context and vocabulary for the panelists' re- 
marks by discussing the purposes of environments, the types 
of environments, the constituents of an environment, the 
Issue of environment Integration, and the problems which 
must be solved In preparing an environment. The paper also 
provides a focus for the panel by proposing some general 
maxims to guide near-term future work and by posing a num- 
ber of questions which the panelists have been asked to 
address In their remarks. 


The process of software development Is slow, costly and error-prone, 
The problem seems to be that, unlike other creative disciplines, computer 
science lacks both a sufficient understanding of the properties of the 
products being developed and an adequate set of principles, practices and 
procedures for guiding the development process and reasoning about the soft 
ware system as It Is being developed. Even the most cursory comparison to 
analogous disciplines such as art, architecture, carpentry, etc., uncovers 
the immaturity of the discipline of software development. 

Recently, solutions to this problem have been sought by preparing 
software development environments which provide facilities supporting the 
rational production of a software system's executable description. Such 
environments are intended to support not only the agglomeration and evolu- 
tion of the system's description but also the assessment of Its validity 
and quality and the exploration of alternative versions. 

The purpose of this panel is to provide some assessment, based on ex- 
perience, of the current status in the area of software development 
environments. This paper provides a context and vocabulary for the 
panelists' remarks by discussing the purposes of environments, the types 

This work was supported, In part, by grant NS6 1638 from NASA Langley 
Research Center. 


- 2 - 


of environments, the constituents of an environment, the issue of environ- 
ment Integration, and the problems which must be solved in preparing an 
environment. The paper also provides a focus for the panel by proposing 
some general maxims to guide near-term future work and by posing a number 
of questions which the panelists have been asked to address in their remarks. 

AIMS OF A DEVELOPMENT ENVIRONMENT 

The primary purpose of a software development environment is to 
provide a context for the orderly, rational evolution of software systems. 

The premise Is that aid in performing development activities Is crucial to 
attaining an acceptable system, on schedule and with a reasonable consump- 
tion of resources; the approach is to support the use of development tech- 
niques and the observance of development principles during the development 
process; and the hope is that progress will be more steadily and quickly 
made. 

A narrow definition of software development would encompass those 
activities which follow the definition of requirements and result in the 
delivery of an acceptable system. However, for two reasons we consider 
development to encompass all activities during the system’s lifetime from 
its initial conception as a set of user or customer desires to its ultimate 
retirement. First, much of the support for development activities in the 
narrow sense are of value in performing other activities such as maintenance. 
Second, we feel that these other activities are not fundamentally different 
and that it is a mistake to consider them to be separable. 

Software development environments which realize this central goal re- 
quire a number of fundamental capabilities. Foremost is the capability to 
extract information about the system under development from the developers 
and organize this information into a coherent body of knowledge. This ex- 
traction and organization is obviously hard to do fully automatically, but 
something more Is needed than simple facilities for recording information 
and Interrelationships among pieces of information. 

Also required Is the capability to assess the consistency and impli- 
cations of the recorded information. The assessment of consistency allows 
developers to gain confidence in the suitability and quality of their work 
- for example, if there are no contradictions between information describing 
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a design and information describing the system's requirements then it is 
fairly safe to assume that the design is an appropriate one. The ability 
to assess the implications of the information provides the bas 4 s for making 
meaningful progress - by Identifying decisions yet to be made and the in- 
formation impacting and constraining the decisions - and allocating project 
resources. 

To complement the capabilities to accumulate and assess information, 
the capability is required to retrieve information in a variety of forms. 
Partially, this is necessary because of the need to produce a large number 
of documents, for example, user manuals, code, maintenance manuals, design 
documentation, etc. Partially, it is necessary because developers need to 
be able to periodically regain a perspective of the system's characteristics. 

The necessity of these general capabilities reflects the view that 
software system development, In tne extended sense embraced here, is an in- 
formation agglomeration task. The product at any point during development 
is a record of what is known about the system and the persons having legit- 
imate interest in the system have a variety of needs for visibility into 
this record. The task at any point is to evolve the information either 
by adding new information reflecting new decisions or by eliminating in- 
ternal inconsistencies existing because of incorrect decisions or because 
of changes to existing information. The purpose of a software development 
environment is, in essence, to facilitate, foster and rationalize the 
agglomeration of information. 

CONSTITUENTS OF AN ENVIRONMENT 

The facilities provided by ^ software development environment are 
delivered by to^ls. The more conspicious tools constituting an environ- 
ment are computer programs, such as compilers,, which augment the developers' 
"powers" in much the same way a saw augments a carpenter's powers. Equally 
important are intangible tools which are not implemented as computer programs 
but serve to guide and support the development process. 

The constituent tools making up an environment may be divided into 
three classes. Cognitive tools extend the intellectual powers of the de- 
velopers. They provide procedures, practices and principles which ration- 
alize the development process itself and make it easier for the developers 
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to solve the problem at hand. These tools come in the form of rules, guide- 
lines and methods which focus the attention of the developers upon an appro- 
priate succession of problems to be solved In order to achieve the develop- 
ment of a required system. 

Tools In the second class, notational tools , extend the denotational 
powers of developers. They provide languages in which developers may 
record decisions and their effects. They allow the effective communication 
of information about the evolving system among the interested "agents" who 
are party to the development effort. They allow a record to be prepared 
which is an adequate basis for assessing the extent of progress and for 
identifying the suitability of what has been decided and the aspects of 
the system which have not yet been attacked. 

The third class of tools are augmentive tools which extend the cap- 
abilities of the developers in much the same way in which saws, hammers 
and screwdrivers extend the capabilities of carpenters. Some of these tools 
perform the mundane tasks present in any development activity. Others per- 
form those tasks which require an unfailing rigor and precision which humans, 
subject to fatique and prone to error, cannot always deliver. Still others 
carry out those tasks which even the smartest of humans find beyond their 
capabilities. All of the tools in this class serve to extend the reasoning, 
as opposed to the problem-solving, powers of the developers. 

It is difficult to define tools within any one of these classes without 
also defining tools within the others. For example, focusing upon a specific 
development method, and thereby defining the cognitive tools which embody 
this method, has strong implications for the notational and augmentive 
tools which are compatible with the method and which serve to support it 
and each other. One must, therefore, co-evolve the various tools which are 
part of an environment. 

TYPES OF ENVIRONMENTS 

A wide range of different types of development environments are 
possible. One major factor differentiating these different types is the 
extent to which they focus upon a specific development method. One extreme 
is those development environments, called toolboxes or toolkits , which 
reflect no method in particular but rather provide help to developers no 
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matter what "style" they use (including the use of no "style"!). The 
notatlonal and augmentive tools in these minimally constrictive environ- 
ments are typically minimally related and integrated. Further, the environ- 
ment can usually be employed in the development of almost any type of software 
system. 

At the other extreme are (level pment systems which promulgate a single 
development method. The notational tools and augmentive tools in these types 
of environments are typically highly integrated and exhibit little, if any, 
redundancy. These environments are usually oriented towards the development 
of a single, rather restricted type of software system such as an accounting 
system or a non-linear equation solving system. These systems are akin to 
"plants" in the manufacturing world. 

It is obviously desirable to have an environment which falls somewhere 
between these two extremes. Such a development support system would provide 
some guidance to developers in the form of a development "philosophy" or 
approach which helps them foeus on the important issues at the various 
stages of development. Thus, in terms of the methods provided by a develop- 
ment support system, there would be a collection of complementary ones and 
the developers should assess the environment as "suggestive, helpful and 
supportive" rather than "imposing." Notational and augmentive tools should 
also foster this reaction and should present the developers with a homog- 
enous, integrated context in which to carry out software development. It 
is probable that this type of environment will be oriented towards the 
development of a specific, but relatively broad, type of software system 
if only because this focus is necessary so that the environment is well- 
defined. 

As one moves from toolboxes to development systems, one finds increased 
tool integration: duplication of tools decreases, tool specialization in- 

creases, and the tools complement each other to a greater degree. In an 
integrated collection of tools, the collection itself is more powerful than 
just the collective power of the constituent tools. 

Notice that as the number of methodologies supported by an environment 
varies there is a concomitant variation in the variety and number of languages 
provided by the environment. Thus, another way to achieve integration of 
the constituents in an environment is to focus upon a small set of languages. 
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If done carefully, the result can be an environment that provides a set of 
highly Integrated tools but that supports a wide range of methodologies. 


OTHER ENVIRONMENT CHARACTERISTICS 


In addition to classifying environments with respect to their "fixation" 
upon a development method, there are a number of characteristics which define 
other dimensions along which an environment may be classified. Some of the 
more important of these characteristics are the following; 

§ agents serviced: the environment will provide help to some subset 

of people concerned with the target systems, i.e., the systems pre- 
pared with the help of the development environment (customers, users, 
requirements definers, designers, programmers, acceptance testers, 
verifiers, trainers, managers, accountants, maintainers, modifiers, 
etc.); 

• aJiaraateristics of target systems: the systems which can be 

developed with the aid of the environment will span some subset 
of data processing concepts (data management, numerical compu- 
tation, text processing, real-time control, parallel processing, 
concurrent processing, distributed processing multiprogrammina, 
etc.); 

• development phase: the environment will be oriented toward some 

subset of the lifecycle of the target systems (requirements defini- 
tion, system definition, architecture design, algorithm design, 
program implementation, system implementation); 

• properties of interest: the environment will support the reasoning 

about the target system's functionality, performance and/or 
economics; 

• development task: the environment will aid in performing some 

or all of the tasks which must be carried out during development 
(creation of a solution, certification of the solution, or ex- 
ploration of alternative solutions); 

• development activity: some or all of the activities performed 

by the agents concerned with the target systems will be supported 
(bookkeeping, supervision, management, decision-making, etc.). 

These characteristics define a multi-dimensional space and a particular 
development environment will be oriented toward some subset of the possibilities 
along each dimension. 


PROBLEMS IN THE PREPARATION OF DEVELOPMENT ENVIRONMENTS 


To prepare a development environment a number of problems must be 
solved. Since an environment is itself a software system, these problems 



mjm 


could be organized along the lines of the traditional life-cycle for soft- 
ware systems, It is more interesting, however, to group the problems somewhat 
differently from (although isomorphically to) the traditional life-cycle view 
since this different organization more clearly identifies alternative approaches 
to the preparation of an environment. 

The problems which must be solved during the preparation of a develop- 
ment environment may be organized as follows: 

• aaope problem: the environment must be placed within the multi- ‘ 
dimensional space defined in the previous section’, 

9 capability problem : the capabilities which the environment will 
provide (so that the various agents may perform their activities 
and tasks during the various phases in the development of the 
target systems) must be identified: 

• techniques! problem: techniques Implementing the required cap- 
abilites must be developed (or identified and borrowed): 

• delivery problem: the environment's organization must be determined, 
consideration must be taken of the computing facility on which the 
environment will execute, and the human-engineering aspects of the 
environment must be addressed; 

9 training problem: development practitioners must be educated in 
the use of the environment and helped to understand how to 
effectively use it (since the latter may necessitate approaching 
the development of systems In ways different from established 
practices); 

9 evaluation problem: the efficacy of the environment must be measured. 

The statement of these problems is suggestive of one order In which they 
can be addressed. Obviously, a totally sequential solution of these problems 
In the order given Is not possible since the problems are highly interrelated. 
The evaluation problem, for example, requires that some consideration be 
given to it during the solution of the delivery problem so that the necessary 
Information for evaluation may be extracted during the use of the environment. 
Nonetheless, attacking these problems in the order given Is a reasonable 
approach. It necessitates, however, a subscription to an overall approach 
to preparation which is heavily exploratory nature, This Is not at all 
unusual for systems, such as environments, for which there are no prototypical 
Implementations. 


SOME DESIRABLE ATTRIBUTES 

Regardless of the type of a software development environment and its 
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characteristics, there are a number of general attributes which seem appro- 
priate at this poi/it, Perhaps these attributes will be shown undesirable 
once we have more experience in designing, implementing and using software 
development environments; but they do seem to provide some general guidelines 
for preparing development environments in the near future. 

Tools should be Hoys, 1 ' Tools should be as simple as possible and 
should serve a narrowly-defined purpose. The temptation to produce multi- 
purpose, general tools should be resisted in favor of producing single- 
purnose, specific tools. 

Tools should be independently available, Collections of tools should 
have a user interface which allows the individual tools to be used independ- 
ently or sets of tools to be used in any (reasonable) sequence. The tendency, 
evidenced by some programming language-specific development environments, 
to hide Individual tools (e.g., the parser) should be avoided. 

Tools should be catalogued . In addition to their function, tools 
have many characteristics which are important to know when deciding whether 
or not to use them. Somt‘ of these characteristics are: assumed user sophis- 
tication, assumed development method, types of systems being built, and 
user development strategy. 

Tools should be methodology independent. A development method, i.e., 
an overall appraoch to the development process, can be rigorously defined as 
a set of rules for how to use a collection of tools to carry out the develop- 
ment process. The best tools are ones which can be used to support a variety 
of methodologies and therefore themselves minimally impose constraints upon 
their useage. 

Rotational tools should be numerous and simple. Many things must be 
described about a system during its development, and it is better to have a 
number of compatible languages, each with a single purpose, than to put 
everything into one language. 

Rotational tools should allow modelling. Each language should provide 
abstraction capabilities so that it is possible to not only highlight specific 
aspects but specify these aspects to an appropriate level of detail. 
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The notational tools ' semantics should he developed first. Each language 
should admit rigorously defined models. The formal foundation for the lan- 
guage should be carefully and fully developed prior to determining a user- 
friendly syntax for describing models based on this foundation. 

"Old programs™ never dle t they Just become designers . " Therefore, 
languages for describing operational aspects of a system should have their 
heritage in programming languages. Further, languages for describing non- 
operational aspects (e.g., behavior) should not use concepts from programming 
languages. 

Augmentive tools should be exceptionally robust, My daughters have an 
unbelievable knack for finding new, innovative and creative ways to use the 
hammers and screwdrivers in our toolbox. This can be expected to be the 
situation with software development tool users also and so the tools should 
be able to withstand unusual, even bizarre, use. They should also protect 
the user from doing (too much) harm. 

Augmentive tools should deliver feedback. It is notoriously difficult 
to algorithmically assess the suitability of a system, Tools to aid this 
assessment should therefore do what can be done and provide developers with 
algorithmically derivable information which the developer can interpret in 
order to determine suitability. 

The premier augmentive tool is a data base. The core of a collection 
of tools should be a data base which retains and organizes all information 
known about the system under development. The data base should allow incon- 
sistent pieces of information to co-exist. All other tools should access the 
Information through the data base management routines. 

EXPERIENCES WITH EXISTING ENVIRONMENTS 

A number cf software development environments have been prepared and 

used. To complement the general discussion of environments presented in 

this paper, reports on experiences with some of these environments will be 

presented by the panelists. These reports will be given by: 

G. Estrin, University of California at Los Angeles 

W. Riddle, University of Colorado 

S. Saib, General Research Corporation 

P. Santoni, Naval Ocean Systems Center 

A. Wasserman, University of California at San Francisco 
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In their reports, these people have been asked to focus on the following 

questions: 

X, What Is the type of your environment and what tools are provided? 

2. How Is the environment organized and to what degree is the 
collection of tools integrated? 

3. Where does the environment sit in the multi-dimensional space 
defined above? 

4. To what extent and how have the problems in preparing software 
development environments been solved? 

5. What were the technical and non-technical influences which shaped 
the nature of the environment? 

6. What were the technical, political, and pragmatic problems 
encountered in preparing the environment? 

7. Do your experiences reinforce or negate the maxims given above 
for guiding near-term future work on environments? 

8. What are the important issues and/or problems to be solved in 
the future in order to provide truly effective development 
environments? 


